Tip: Review these changes grouped by change (recommended for most PRs), or grouped by feature (for large PRs).

I've shipped the new behaviors in Chromium as of version 150:

https://chromestatus.com/feature/6282804208992256

I'm not sure how to recommend we capture that here.

@mfreed7 does that include the bug where clicking on a hint loses it's association with it's parent auto?

In this case, the old behaviour was buggy and pretty hard to use or even explain. So it's not really like "we changed the design", and more "it was full of bugs and we fixed it".

Yes, in this case, the bugs were in the spec & the tests, but from a developer's point of view, the behaviour of the feature was buggy.

I don't mind doing it the way you say, but I wanted to make it clear that this situation is different to other re-designs of behaviour.

I don't think we should merge this as written, nor should we create a behavioral subfeature. Instead, I think we wait until there's an actual difference between two engines and the specification. Only then could we mark the current implementations as partial.

Adding a behavioral subfeature here is… challenging. Some of this might just be the complexity of popover hint itself, but I don't really see a handle for creating a subfeature. Subfeatures tend to mark a difference in kind (e.g., a new return type), a restriction (i.e., a thing you could do before which is now forbidden or a noop), or a new capability. Reading the Chrome Status entry, I'm not seeing a lot that fits neatly into those buckets (except maybe something like "safely nest an auto popover inside a hint popover") and also doesn't invite making several subfeatures.

But going directly to a partial now is confusing and weird. In BCD, our typical stance is to privilege implementations over specifications, when the implementations are compatible (i.e., if three engines all do the same thing, but that same thing is slightly divergent from the spec, then we treat the spec as the faulty one). AFAICT, in today's Firefox and Chrome, you get compatible behavior with popover="hint", so it would be unusual to mark the two compatible implementers as partially implemented.

So when Chrome 150 reaches beta, then I'd expect something like this:

• Chrome
  • Added 150, no partial, no note.
  • Added 133, partial with the proposed note.
• Firefox
  • Partial with the proposed note.

Chrome 150 is a little early to receive this treatment today—we don't typically trust that things that aren't even in a beta to ship in their predicted version number. It probably needs to wait a couple of weeks, unless you're absolutely certain it'll make it to stable without further changes.

AFAICT, in today's Firefox and Chrome, you get compatible behavior with popover="hint",

That is true. It's just that the behaviour is mostly inexplicable.

I think it's misleading to developers to give these implementations a ✅, but I don't feel strongly enough to push for it further. I can wait until it hits beta.

I think there's a difference between "implementations over spec" in general and "implementation over spec" in the specific case where implementations have agreed that the spec is wrong, updated it, and merged changes to align with the spec, even if those changes haven't yet made it into a stable release.

In general I dislike "partial" and would prefer us to avoid it. But in this specific case marking all the existing implementations as "partial" now and then removing the mark once implementations ship the new behaviour seems strictly more helpful to authors than waiting a couple of weeks until the new behaviour reaches beta in Chrome to do essentially the same thing. An author looking to use the feature today doesn't benefit from being told that the behaviour is currently interoperable if that doesn't reflect the situation we expect in a few weeks time. The only benefit of withholding the information would be if we in fact expect that compatibility concerns will result in the changes being reverted. But I don't think that's the case here.

@mfreed7 does that include the bug where clicking on a hint loses it's association with it's parent auto?

Yep, that one made the 150 branch also.

That is true. It's just that the behaviour is mostly inexplicable.

I think "mostly inexplicable" is likely a bit too strong, right? I mean it was explained when it shipped in Chrome the first time, more than a year ago. We've had zero developer bugs about any of these corner cases. I'm glad we cleaned them up, and the new state is definitely better than the old. But my assumption, based on that, the best thing to do in browser compat data is whatever is the "simplest" and most straightforward. And note that Chrome 150 will support the latest landed standard.

I think "mostly inexplicable" is likely a bit too strong, right? I mean it was explained when it shipped in Chrome the first time, more than a year ago.

ehhh I'd say that it glosses over all the weird behaviours by calling them "special" and not going into the details. When I actually tried to detail them… I couldn't justify the behaviours. The article also contains stuff that's plain wrong:

(opening) popover="hint", on the other hand, only force-hides other hint popovers

We know that isn't true. It sometimes does, sometimes doesn't. So… it wasn't explained.

We've had zero developer bugs about any of these corner cases.

You definitely had one. I get it, but I was also told "no one's complaining" about appcache back in the day. More recently, I was given the "no one's complaining" line about my concerns with observables, and again, they turned out to be real issues.

In this case, you're probably not hearing complaints (aside from me, and everyone who I've shown the issues to) because no one's using it, or they weren't aware of the UX bugs that are hitting their users.

And note that Chrome 150 will support the latest landed standard.

Same question as earlier… does that include the bug where clicking on a hint loses it's association with it's parent auto?